Originator(s):cacraig

Description (include issue title and the keyword ['closes', 'fixes',
'resolves'] and issue number):
- During CAM-SIMA regression testing, a number of issues were
discovered. This PR fixes them
      - Needed to introduce a regression test for dme_adjust
- Forgot to comment out dme_adjust in a couple of suites (see #222 )
      - Inadvertently removed a scheme from TJ16

List all namelist files that were added or changed: N/A

List all files eliminated and why: N/A

List all files added and what they do: N/A

List all existing files that have been modified, and describe the
changes:
(Helpful git command: `git diff --name-status
development...<your_branch_name>`)
M       schemes/conservation_adjust/check_energy/check_energy_chng.meta
M
schemes/conservation_adjust/check_energy/check_energy_gmean/check_energy_gmean.meta
- Change relative location for dependencies due to introduction of a new
subdirectory layer
             
M       suites/suite_cam4.xml
M       suites/suite_cam7.xml
M       suites/suite_kessler.xml
M       suites/suite_tj2016.xml
- comment out and/or augment comment for dme_adjust (see #222)
             
M       test/test_suites/suite_dme_adjust.xml
- Add diagnostics scheme so there are baselines for dme_adjust

List all automated tests that failed, as well as an explanation for why
they weren't fixed: N/A

Is this an answer-changing PR? If so, is it a new physics package,
algorithm change, tuning change, etc? N/A

If yes to the above question, describe how this code was validated with
the new/modified features: N/A

Originator(s): @boulderdaze

Summary (include the keyword ['closes', 'fixes', 'resolves'] and issue
number):

- Added the missing error check statements
- Specified the full path for CAM-SIMA to read the MUSICA configuration
- Removed `photolysis wavelength grid interfaces` argument from
`musica_ccpp_run` function as it is set during the init phase and
remains unchanged.
- Created a function to deallocate the photolysis wavelength grid
interfaces that are allocated in `tuvx_init` (specifically in
`musica_ccpp_tuvx_extraterrestrial_flux`). Initially, after calling
`set_extraterrestrial_flux_values`, the allocated wavelength grid
interfaces were deallocated, but these interfaces need to remain
available during the entire run. Now, `tuvx_final` is responsible for
deallocating these interfaces.
- Updated the copyright year in the MUSICA scheme files
- Updated the CMakeLists.txt to reflect the name change in the python
script `ccpp_meta_stdname_check`
- Moved the test data to a separate file that contains the photolysis
wavelength grid interfaces array and extraterrestrial radiation flux
values.
- Tested the CAM-SIMA run on Derecho with the Terminator configurations.

Describe any changes made to the namelist: 

- Specified the full path In `schemes/musica/musica_ccpp_namelist.xml`

List all files eliminated and why: N/A

List all files added and what they do: N/A

List all existing files that have been modified, and describe the
changes:
```
M       schemes/cloud_fraction/set_cloud_fraction_top.F90
M       schemes/musica/micm/musica_ccpp_micm.F90
M       schemes/musica/micm/musica_ccpp_micm_util.F90
M       schemes/musica/musica_ccpp.F90
M       schemes/musica/musica_ccpp.meta
M       schemes/musica/musica_ccpp_namelist.xml
M       schemes/musica/musica_ccpp_species.F90
M       schemes/musica/musica_ccpp_util.F90
M       schemes/musica/tuvx/musica_ccpp_tuvx.F90
M       schemes/musica/tuvx/musica_ccpp_tuvx_aerosol_optics.F90
M       schemes/musica/tuvx/musica_ccpp_tuvx_cloud_optics.F90
M       schemes/musica/tuvx/musica_ccpp_tuvx_extraterrestrial_flux.F90
M       schemes/musica/tuvx/musica_ccpp_tuvx_gas_species.F90
M       schemes/musica/tuvx/musica_ccpp_tuvx_height_grid.F90
M       schemes/musica/tuvx/musica_ccpp_tuvx_load_species.F90
M       schemes/musica/tuvx/musica_ccpp_tuvx_surface_albedo.F90
M       schemes/musica/tuvx/musica_ccpp_tuvx_temperature.F90
M       schemes/musica/tuvx/musica_ccpp_tuvx_wavelength_grid.F90
M       test/docker/Dockerfile.musica
M       test/docker/Dockerfile.musica.no_install
M       test/musica/CMakeLists.txt
M       test/musica/micm/test_micm_util.F90
M       test/musica/musica_ccpp_namelist.F90
A       test/musica/musica_test_data.F90
M       test/musica/test_musica_api.F90
M       test/musica/test_musica_species.F90
M       test/musica/tuvx/CMakeLists.txt
M       test/musica/tuvx/test_tuvx_aerosol_optics.F90
M       test/musica/tuvx/test_tuvx_cloud_optics.F90
M       test/musica/tuvx/test_tuvx_extraterrestrial_flux.F90
M       test/musica/tuvx/test_tuvx_gas_species.F90
M       test/musica/tuvx/test_tuvx_height_grid.F90
M       test/musica/tuvx/test_tuvx_load_species.F90
M       test/musica/tuvx/test_tuvx_surface_albedo.F90
M       test/musica/tuvx/test_tuvx_temperature.F90
M       test/musica/tuvx/test_tuvx_wavelength_grid.F90
M       to_be_ccppized/ccpp_tuvx_utils.F90
```
List any test failures: N/A

Is this a science-changing update? New physics package, algorithm
change, tuning changes, etc? No

Originator(s): @mwaxmonsky @nusbaume 

Description (include issue title and the keyword ['closes', 'fixes',
'resolves'] and issue number):

This PR contains a File I/O class as designed by myself and (mostly)
@mwaxmonsky. This current version should be able
to read in any integer, real, or character-type variable from a NetCDF
file, up to a five-dimensional array. Currently
the entire variable will be read, but a future PR will also allow for
variable subsetting, particularly for the record dimension
(as that is required for multiple CAM-SIMA use cases).

A few notes on the design:

1. The major goal of this work is to create a File I/O interface that is
host model independent. We believe
we have accomplished that but if you see anything that appears
SIMA-specific please let us know!

2. The class is designed to allocate a variable's memory on the host
model side. This was done with the idea
that a host model might have a more sophisticated way of managing memory
then just putting it on the heap (e.g. a memory pool).

3. We were torn on how many capabilities the FileIO class should have.
We decided to keep the functionality low to reduce
complexity, but if there are strong feelings otherwise please let us
know! In particular we are leaning towards making
the necessary regridding/interpolation steps a separate class, so that
we don't have too much inter-mingling of functionality
    in a single location.

Anyways, any thoughts, comments, suggestions, or review requests would
be greatly appreciated! The corresponding CAM-SIMA PR is
ESCOMP/CAM-SIMA#385. Thanks!

Fixes #241

List all namelist files that were added or changed:

A       test/test_schemes/file_io_test_namelist.xml
- Namelist file for file I/O test scheme which can be used to specify
the test NetCDF file(s).

List all files eliminated and why: N/A (no files removed)

List all files added and what they do:

A       phys_utils/ccpp_io_reader.F90
 - Initial File I/O reader type declarations
 
A       test/test_schemes/file_io_test.F90
A       test/test_schemes/file_io_test.meta
A       test/test_suites/suite_file_io_test.xml
- File I/O test scheme and suite for use in CAM-SIMA testing (will be
removed once a more complete/automated testing system has been
developed).

List all existing files that have been modified, and describe the
changes: N/A (no files were modified).
(Helpful git command: `git diff --name-status
development...<your_branch_name>`)

List all automated tests that failed, as well as an explanation for why
they weren't fixed: All tests pass.

Is this an answer-changing PR? If so, is it a new physics package,
algorithm change, tuning change, etc?

If yes to the above question, describe how this code was validated with
the new/modified features:

---------

Co-authored-by: Michael Waxmonsky <mwaxmonsky@ucar.edu>

Originator(s): peverwhee

Description (include issue title and the keyword ['closes', 'fixes',
'resolves'] and issue number):
Unfortunately, due to inconsistent compiler support, this PR removes the
fancy assumed rank parts of the file i/o object and replaces them with
an interface for each dimension/type.

List all namelist files that were added or changed: n/a

List all files eliminated and why: n/a

List all files added and what they do: n/a

List all existing files that have been modified, and describe the
changes:
(Helpful git command: `git diff --name-status
development...<your_branch_name>`)

M phys_utils/ccpp_io_reader.F90
- Break into dimension-specific interfaces

List all automated tests that failed, as well as an explanation for why
they weren't fixed: n/a

Is this an answer-changing PR? If so, is it a new physics package,
algorithm change, tuning change, etc? No

If yes to the above question, describe how this code was validated with
the new/modified features:

Originator(s): Matt Dawson

Description (include issue title and the keyword ['closes', 'fixes',
'resolves'] and issue number): Updates to use the latest version of the
MUSICA library. closes #246
- Uses new MICM state type for directly interacting with MICM state
data, avoiding copies.
- Allows use of vectorizable matrix with Rosenbrock or Backward Euler
solver
- Removes double creation of MICM solver now that the number of grid
cells is only needed when creating a MICM state, instead of when the
solver is created
- Adds an integration test for an analytical chemistry system using
various numbers of grid cells and both solver types.
- Runs MUSICA tests on pushes to main and development, instead of just
on PRs to be consistent with other unit testing

List all namelist files that were added or changed:
none
List all files eliminated and why:
none
List all files added and what they do:
test code and configuration files
List all existing files that have been modified, and describe the
changes:
(Helpful git command: `git diff --name-status
development...<your_branch_name>`)
musica scheme files and tests only
List all automated tests that failed, as well as an explanation for why
they weren't fixed:
none
Is this an answer-changing PR? If so, is it a new physics package,
algorithm change, tuning change, etc?
no
If yes to the above question, describe how this code was validated with
the new/modified features:

Originator(s): peverwhee

Description (include issue title and the keyword ['closes', 'fixes',
'resolves'] and issue number):
The newest framework tag has checking for proper horizontal dimensions
(depending on the phase), so this just fixes two instances of the
incorrect horizontal dimension being used.

List all namelist files that were added or changed: n/a

List all files eliminated and why: n/a

List all files added and what they do: n/a

List all existing files that have been modified, and describe the
changes:
(Helpful git command: `git diff --name-status
development...<your_branch_name>`)
M   schemes/sima_diagnostics/check_energy_fix_diagnostics.meta
M   schemes/tropopause_find/tropopause_find.meta
 - replace horizontal_dimension with horizontal_loop_extent in run phase

List all automated tests that failed, as well as an explanation for why
they weren't fixed:

Is this an answer-changing PR? If so, is it a new physics package,
algorithm change, tuning change, etc? no

If yes to the above question, describe how this code was validated with
the new/modified features:

### Originator(s):

kuanchihwang

### Descriptions (include the issue title, and the keyword ['closes',
'fixes', 'resolves'] followed by the issue number):

This PR introduces the new *EXPERIMENTAL* "convection-permitting"
physics suite. YSU orographic gravity wave drag scheme is the first
physics scheme to be ported and included.

YSU orographic gravity wave drag scheme is part of MMM physics, which is
brought in as an external dependency (i.e., git submodule) and is shared
between MMM models (e.g., MPAS, WRF). However, due to the significant
architectural and design differences between CAM-SIMA and MMM models, a
CCPP-compliant compatibility layer is implemented to transparently
convert procedure calls between CCPP physics caps and MMM physics. This
design decision is also influenced by the request of MMM scientists. The
MMM physics repository will only house the "primary schemes", while
their associated "interstitial schemes" as well as metadata files will
be brought here. Therefore, CCPP physics caps will not interface MMM
physics directly, but will do so through the compatibility layer
instead.

### List all namelist files that were added or changed:

None

### List all files eliminated and why:

None

### List all files added and what they do:

```
A       .gitmodules
A       schemes/mmm/mmm_physics
  * Add MMM physics as git submodule
A       schemes/mmm/bl_gwdo_compat.F90
A       schemes/mmm/bl_gwdo_compat.meta
  * Add compatibility layer for YSU orographic gravity wave drag scheme
A       schemes/mmm/ccpp_kind_types.F90
A       schemes/mmm/mmm_physics_compat.F90
A       schemes/mmm/mmm_physics_compat.meta
  * Add compatibility layer for MMM physics
A       schemes/mmm/CMakeLists.txt
  * Enable CMake to build MMM physics compatibility layer
A       test/test_suites/suite_convection_permitting.xml
  * Add suite definition file for the new "convection-permitting" physics suite
A       test/unit-test/tests/mmm/CMakeLists.txt
A       test/unit-test/tests/mmm/mmm_physics_compat_tests.pf
  * Enable testing for MMM physics compatibility layer
```

### List all existing files that have been modified, and describe the
changes:

```
M       test/unit-test/CMakeLists.txt
M       test/unit-test/tests/CMakeLists.txt
  * Enable testing for MMM physics compatibility layer
```

### List all automated tests that failed, as well as an explanation for
why they were not fixed:

None

### Is this an answer-changing PR? If so, is it a new physics package,
algorithm change, tuning change, etc?

Answer-changing for the convection-permitting physics suite due to a
newly added physics scheme. Nothing is changed for the rest.

### If yes to the above question, describe how this code was validated
with the new/modified features:

The convection-permitting physics suite is considered an experimental
feature. There is no baseline available to validate against because it
has never been implemented in CAM-SIMA as well as CAM before.

Originator(s): @jimmielin

Description (include issue title and the keyword ['closes', 'fixes',
'resolves'] and issue number):
- Closes #190 completes conversion of rk_stratiform microphysics to CCPP

List all namelist files that were added or changed: N/A

List all files eliminated and why: N/A

List all files added and what they do:
```
A       schemes/sima_diagnostics/compute_cloud_fraction_diagnostics.F90
A       schemes/sima_diagnostics/compute_cloud_fraction_diagnostics.meta
A       schemes/sima_diagnostics/convective_cloud_cover_diagnostics.F90
A       schemes/sima_diagnostics/convective_cloud_cover_diagnostics.meta
  - cldfrc diagnostic schemes,
  - including split out shallow/deep convective cloud cover in convective_cloud_cover scheme

A       schemes/sima_diagnostics/cloud_particle_sedimentation_diagnostics.F90
A       schemes/sima_diagnostics/cloud_particle_sedimentation_diagnostics.meta
A       schemes/sima_diagnostics/rk_stratiform_diagnostics.F90
A       schemes/sima_diagnostics/rk_stratiform_diagnostics.meta
  - RK diagnostic schemes
```

List all existing files that have been modified, and describe the
changes:
(Helpful git command: `git diff --name-status
development...<your_branch_name>`)
```
M       schemes/cloud_fraction/compute_cloud_fraction.meta
M       schemes/cloud_fraction/convective_cloud_cover.meta
M       schemes/hack_shallow/hack_convect_shallow.meta
M       schemes/rasch_kristjansson/cloud_particle_sedimentation.F90
M       schemes/rasch_kristjansson/cloud_particle_sedimentation.meta
M       schemes/rasch_kristjansson/prognostic_cloud_water.F90
M       schemes/rasch_kristjansson/prognostic_cloud_water.meta
M       schemes/rasch_kristjansson/rk_stratiform.meta
  - update with assigned standard names
  - minor cleanup of unused variables
```

List all automated tests that failed, as well as an explanation for why
they weren't fixed:
N/A

Is this an answer-changing PR? If so, is it a new physics package,
algorithm change, tuning change, etc?
N/A - SIMA diagnostics only

If yes to the above question, describe how this code was validated with
the new/modified features:
N/A

Originator(s): Matt Dawson

Description (include issue title and the keyword ['closes', 'fixes',
'resolves'] and issue number):
- Updates the MUSICA suite file to include diagnostics so we can include
chemical species in the output files.
- Updates the MICM wrapper to output warnings to the log file when the
solver fails.
- Updates to the latest version of the MUSICA library

List all namelist files that were added or changed:
none

List all files eliminated and why:
none

List all files added and what they do:
none

List all existing files that have been modified, and describe the
changes:
(Helpful git command: `git diff --name-status
development...<your_branch_name>`)
| File | Description |
| ------------------------------------- |
------------------------------------------------------------------------
|
| test/musica/test_musica_api.F90 | Introduce `STDOUT` constant and
update calls to `musica_ccpp_run` to pass log unit |
| test/docker/Dockerfile.musica.no_install | Bump `MUSICA_GIT_TAG` and
switch `BUILD_TYPE` to Release |
| test/docker/Dockerfile.musica | Bump `MUSICA_GIT_TAG` and switch
`BUILD_TYPE` to Release |
| suites/suite_musica.xml | Add `sima_state_diagnostics` scheme and a
comment for state diagnostics |
| schemes/musica/musica_ccpp.meta | Define new `log_output_unit`
parameter in metadata |
| schemes/musica/musica_ccpp.F90 | Add `log_output_unit` argument to
`musica_ccpp_run` interface |
| schemes/musica/micm/musica_ccpp_micm.F90 | Add `log_output_unit` to
`micm_run` and emit solver failure warnings |

List all automated tests that failed, as well as an explanation for why
they weren't fixed:
none

Is this an answer-changing PR? If so, is it a new physics package,
algorithm change, tuning change, etc?
It should only affect answers for chemistry

If yes to the above question, describe how this code was validated with
the new/modified features:

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Originator(s): peverwhee

Description (include issue title and the keyword ['closes', 'fixes',
'resolves'] and issue number):
**Brings in CCPP-ized longwave Fortran modules for RRTMGP.**

The order of the schemes in the SDF will eventually be:
- rrtmgp_lw_gas_optics_data
- rrtmgp_pre
- tropopause_find (already CCPP-ized)
- rrtmgp_inputs
- rrtmgp_lw_cloud_optics
- rrtmgp_lw_mcica_subcol_gen
- LW diagnostics subcycle:
  - rrtmgp_lw_gas_optics_pre
  - rrtmgp_lw_gas_optics
  - rrtmgp_lw_main
  - rrtmgp_lw_diagnostics (does not exist yet)
- rrtmgp_dry_static_energy_tendency
- calculate_net_heating
- rrtmgp_post 

addresses #154 

List all namelist files that were added or changed: n/a

List all files eliminated and why: n/a

**List all files added and what they do:**

A   phys_utils/atmos_phys_string_utils.F90
- string utils functionality for atmospheric_physics (to_lower and
to_upper for now

A   schemes/rrtmgp/objects/ccpp_fluxes.F90
A   schemes/rrtmgp/objects/ccpp_fluxes.meta
A   schemes/rrtmgp/objects/ccpp_fluxes_byband.F90
A   schemes/rrtmgp/objects/ccpp_fluxes_byband.meta
A   schemes/rrtmgp/objects/ccpp_gas_concentrations.F90
A   schemes/rrtmgp/objects/ccpp_gas_concentrations.meta
A   schemes/rrtmgp/objects/ccpp_gas_optics_rrtmgp.F90
A   schemes/rrtmgp/objects/ccpp_gas_optics_rrtmgp.meta
A   schemes/rrtmgp/objects/ccpp_optical_props.F90
A   schemes/rrtmgp/objects/ccpp_optical_props.meta
A   schemes/rrtmgp/objects/ccpp_source_functions.F90
A   schemes/rrtmgp/objects/ccpp_source_functions.meta
- RRTMGP object wrappers and corresponding metadata

A   schemes/rrtmgp/rrtmgp_inputs.F90
- CCPP-ized core rrtmgp_set_state from rrtmgp_inputs.F90 in CAM (setting
up the LW and SW inputs)
- SIMA-specific interstitial

A   schemes/rrtmgp/rrtmgp_lw_cloud_optics.F90
- CCPP-ized longwave cloud optics (rrtmgp_set_cloud_lw from
rrtmgp_inputs in CAM)
- SIMA-specific scheme (CAM does not use the built-in RRTMGP cloud
optics)

A   schemes/rrtmgp/rrtmgp_lw_gas_optics.F90
- CCPP-ized longwave gas optics calculation (rrtmgp_set_gases_lw from
rrtmgp_inputs in CAM)
- This scheme will be shared with NOAA

A   schemes/rrtmgp/rrtmgp_lw_gas_optics_data.F90
- CCPP-ized longwave gas optics initialization/load (contains only an
"init" phase)
- Basically the CCPP-ized version of coefs_init from radiation.F90 in
CAM (LW)
- This scheme will be shared with NOAA
- Is separate from rrtmgp_lw_gas_optics.F90 because init has to come
before cloud_optics_init and run has to come after cloud_optics_run

A   schemes/rrtmgp/rrtmgp_lw_gas_optics_pre.F90
- CCPP-ized prep for gas optics calculation (rrtmgp_lw_gas_optics)
- SIMA-specific interstitial

A   schemes/rrtmgp/rrtmgp_lw_main.F90
- CCPP-ized interface to the RTE LW calculation
- This scheme will be shared with NOAA

A   schemes/rrtmgp/rrtmgp_lw_mcica_subcol_gen.F90
- CCPP-ized module for McICA subcolumn generation
- SIMA-specific, non-portable scheme (depends on shr_RandNum_mod.F90)

A   schemes/rrtmgp/rrtmgp_post.F90
- CCPP-ized post-SW and LW calculations and object clean-up
- SIMA-specific interstitial

A   schemes/rrtmgp/rrtmgp_pre.F90
- CCPP-ized pre-SW and LW calculations and object
allocation/initialization
- SIMA-specific interstitial

A   schemes/rrtmgp/utils/calculate_net_heating.F90
- CCPP-ized radheat.F90 from CAM

A   schemes/rrtmgp/utils/radiation_tools.F90
- This is a duplicate of the radiation_tools.F90 in
ccpp-physics/physics/Radiation/
- The only routine we're currently using is check_error_msg
- Will be removed when we bring in ccpp-physics
- Will be shared with NOAA

A   schemes/rrtmgp/utils/radiation_utils.F90
- Non-ccpp-ized routines used by both shortwave and longwave
- SIMA-specific

A   schemes/rrtmgp/utils/rrtmgp_dry_static_energy_tendency.F90
- CCPP-ized scheme to calculate dry static energy tendency (qrl and qrs)

List all existing files that have been modified, and describe the
changes: n/a
(Helpful git command: `git diff --name-status
development...<your_branch_name>`)

List all automated tests that failed, as well as an explanation for why
they weren't fixed:

Is this an answer-changing PR? If so, is it a new physics package,
algorithm change, tuning change, etc? b4b in CAM

If yes to the above question, describe how this code was validated with
the new/modified features:

---------

Co-authored-by: Courtney Peverley <courtneyp@izumi.cgd.ucar.edu>